每个小孩刚开始走路的时候都是跌跌撞撞的。 我们不自量力，妄图踩着上帝的步伐前进。结果就是这么几个简单的象白开水似的类。失望吗？是不是造物试图模仿造物主本身就是一种可笑的狂妄呢？
别急，让我们失声痛哭之前先看看我们这几步走的是不是一钱不值。
1。logger可以把信息打印到log文件中。
容易，直接创建一个WriterLogger就好了。
2。不同的重要程度的信息也许可以打印到不同的文件中？象websphere，有error.log, info.log等。 如果这样，那么什么重要程度的信息进入error.log，什么进入warning.log，什么进入info.log也需要决定。
不同的文件吗？好办啊。就是不同的PrintWriter对象了。 java代码:
Logger err_log = writer(err_writer);
Logger warning_log = writer(warning_writer);
Logger info_log = writer(info_writer);
各个文件记录不同重要程度的信息是么？ java代码:
err_log = filter(ERROR, err_log, nop());
warning_log = filter(WARNING, warning_log, nop());
info_log = filter(INFO, info_log, nop());
最终把三个不同的logger串联起来就是了： java代码:
Logger logger = sequence(err_log, warning_log, info_log);
3。也许可以象ant一样把所有的信息都打印到一个文件中。
这就更简单了，就一个是WriterLogger。
4。每条logging信息是否要同时打印当前的系统时间？也是一个需要抉择的问题。
拿不定主意是么？没关系，想好了再告诉我。 反正，如果你需要系统时间，我只需要 java代码:
logger = timestamp(logger);
5。不仅仅是log文件，我们还希望能够在标准错误输出上直接看见错误，普通的信息可以打印到log文件中，对错误信息，我们希望log文件和标准输出上都有。
可以创建针对标准输出的Logger，然后和打印log 文件的logger串联起来。 java代码:
Logger std_logger = writer(new PrintWriter(System.err));
std_logger = ignore(ERROR, std_logger);
logger = sequence(std_logger, logger);
6。标准输出上的东西只要通知我们出错了就行，大概不需要详细的stack trace，所以exception stack trace可以打印到文件中，而屏幕上有个简短的exception的message就够了。
这里需要对std_logger稍微改写一下： java代码:
PrintWriter out = new PrintWriter(System.err);
std_logger = new ErrorMessageLogger(out, writer(out));
std_logger = ignore(ERROR, std_logger, nop());
用ErrorMessageLogger来改写对异常的log逻辑。
7。warning似乎也应该输出到屏幕上。
好啊。就是把ignore函数里面的ERROR换成WARNING就好了 java代码:
std_logger = ignore(WARNING, std_logger, nop());
8。不管文件里面是否要打印当前系统时间，屏幕上应该可以选择不要打印时间。
对std_logger不掉用timestamp就是了。
9。客户应该可以通过命令行来决定log文件的名字。
这条和logger组合子其实没什么关系。
10。客户可以通过命令行来决定log的细节程度，比如，我们只关心info一样级别的信息，至于debug, verbose的信息，对不起，不要打印。
生成那个最终使用的Logger对象的时候，再ignore一下就行了：
java代码:
logger = ignore(some_level, logger, nop());
11。neptune生成的是一些Command对象，这些对象运行的时候如果出现exception，这些exception会带有execution trace，这个execution trace可以告诉我们每个调用栈上的Command对象在原始的neptune文件中的位置（行号）。 这种exception叫做NeptuneException，它有一个printExecutionTrace(PrintWriter)的方法来打印execution trace。 所以，对应NeptuneException，我们就不仅仅是printStackTrace()了，而是要在printStackTrace()之前调用printExecutionTrace()。
NeptuneExceptionLogger就是给这个准备的呀。
12。neptune使用的是jaskell语言，如果jaskell脚本运行失败，一个EvaluationException会被抛出，这个 类有一个printEvaluationTrace(PrintWriter)的方法来打印evaluation trace，这个trace用来告诉我们每个jaskell的表达式在脚本文件中的位置。 所以，对应EvaluationException，我们要在printStackTrace()之前，调用printEvaluationTrace()。
JaskellExceptionLogger
13。execution trace和evaluation trace应该被打印到屏幕上和log文件两个地方。
这就是说，上面两个Logger应该被应用到std_logger和logger两个对象中。
14。因为printExecutionTrace()和printEvaluationTrace()本身已经打印了这个异常的getMessage()，所以，对这两种异常，我们就不再象对待其它种类的异常那样在屏幕上打印getMessage()了，以免重复。
就是说，一旦一个exception被发现是NeptuneException，那么ErrorMessageLogger就要被跳过了。 java代码:
final Logger err_logger = new ErrorMessageLogger(writer);
final Logger jaskell_logger = new JaskellExceptionLogger(writer, err_logger);
final Logger neptune_logger = new NeptuneExceptionLogger(writer, jaskell_logger);
return neptune_logger;
这个neptune_logger先判断异常是不是NeptuneException，如果是，直接处理，否则，传递给 jaskell_logger。jaskell_logger继续判断，如果不是它感兴趣的，再传递给ErrorMessageLogger来做最后的缺 省处理。
15。也许还有一些暂时没有想到的需求， 比如不是写入log文件，而是画个图之类的变态要求。
放马过来吧。看我们的组合子能不能对付。
很惊讶地发现，就这么几个小儿科似的积木，就似乎全部解决了曾让我们烦恼的这些需求？
为了给大家一个完整的印象，下面是我实际项目中使用这些组合子应对上面这些需求的代码： java代码:
public class StreamLogger {
private final OutputStream out;
/**
* To create a StreamLogger object.
* @param out the OutputStream object that the log message should go to.
*/
public StreamLogger(OutputStream out) {
this.out = out;
}
/**
* To get the OutputStream that the log messages should go to.
*/
public OutputStream getStream() {
return out;
}
private static Logger getBaseLogger(PrintWriter writer){
final Logger nop = new NopLogger();
final Logger base = Loggers.logger(writer);
final Logger neptune_logger = new NeptuneExceptionLogger(writer, nop);
final Logger jaskell_logger = new JaskellExceptionLogger(writer, nop);
return Loggers.sequence(
new Logger[]{neptune_logger, jaskell_logger, base}
);
}
private static Logger getEchoLogger(PrintWriter writer){
return new ErrorMessageLogger(writer);
}
private static Logger getErrorLogger(PrintWriter writer){
final Logger err_logger = new ErrorMessageLogger(writer);
final Logger jaskell_logger = new JaskellExceptionLogger(writer, err_logger);
final Logger neptune_logger = new NeptuneExceptionLogger(writer, jaskell_logger);
return neptune_logger;
}
/**
* Get the Logger instance.
* @param min_level the minimal critical level for a log message to show up in the log.
* @return the Logger instance.
*/
public Logger getDefaultLogger(int min_level){
final PrintWriter writer = new PrintWriter(out, true);
final PrintWriter err = new PrintWriter(System.err, true);
final PrintWriter warn = new PrintWriter(System.out, true);
final Logger all = Loggers.sequence(new Logger[]{
Loggers.ignore(getErrorLogger(err), Logger.ERROR),
Loggers.filter(getEchoLogger(warn), Logger.WARNING),
getBaseLogger(writer)
}
);
return Loggers.ignore(all, min_level);
}
}
为了偷懒，我没有用配置文件，就是把这些策略硬编码进java了。好在上面的代码非常declarative，改起来也很容易。
没习惯读代码的朋友。这里奉劝还是读一读吧。很多时候，代码才是说明问题的最好手段。我相信，只有读了代码，你才能真正尝到CO的味道。
有朋友问，你这个东西和decorator pattern有什么区别呀？乍看上去，还真是长得差不多呢。不都是往现有的某个对象上面附加一些功能吗？ 也许是把。我不知道象SequenceLogger这种接受一个数组的，是否也叫做对数组的decorator；也不知道IgnoreLogger接受了两个Logger对象，这个decorator究竟是修饰谁的呢？
其实，叫什么名字无所谓。我这里要讲的，是一种从基本粒子推演组合的思路。形式上它也许碰巧象decorator, 象ioc。但是正如workinghard所说（这句话深得我心），思路的切入点不同。
如果你仔细看上面的代码，也许你会有所感觉：对Logger的千奇百怪的组合本身已经有点象一个程序代码了。 如果用伪码表示：
java代码:
all_logger = ignore messages below ERROR for getErrorLogger(err);
filter messages except WARNING for getEchoLogger(warn);
baseBaseLogger(writer);
ignore messages below lvl for all_logger;
当组合子越来越多，需求越来越复杂，这个组合就会越来越象个程序。
这里，实际上，（至少我希望如此），我们的思维已经从打印什么什么东西上升为在Logger这个级别的组装了。
这也就是所谓higher order logic的意思。
所谓combinator-oriented，在这里，就体现为系统性地在高阶逻辑的层面上考虑问题，而不是如decorator那样的零敲碎打的几个功能模块。 大量的需求逻辑被以声明式的方式在高阶逻辑中实现，而基本的组合子只负责实现原字操作。
当然，缺点也是明显的，对此我不讳言：
高阶逻辑不容易调试，当我们使用一个组合了十几层的复杂的Logger对象的时候（真正用了co这种情况不少见），一旦出现bug，跟踪的时候我们就会发现象是陷入了一个迷宫，从一个组合子跟踪进入另一个组合子，绕来绕去。
另外，异常的stack trace也无法反映组合层次关系，造成错误定位麻烦。
这也许不是co本身的问题，而是因为java这种oo语言对co没有提供语言上的支持。但是无论如何，这对在java中大规模使用co造成了障碍。
也许你还无法理解。平时我们在java中用那么几个decorator，本身非常简单，所以debug, trace都不是问题。可是，一旦oriented起来，情况就不同了。街上有两辆车和成千上万辆车，对交通造成的压力截然不同。
还有朋友，对co如何把握有疑问。难道co就是瞎猫碰死耗子么？
其实，无论co还是oo，对设计者都是有一定要求的。 oo要求你了解需求，并且经验丰富，也要有一点点运气。 co也要求经验，这个经验是设计组合子系统的经验。什么样的组合子是好的？怎么才算是足够简单？什么组合规则是合理的？等等，这些，也有规律可循，就像oo的各种模式一样。同时，也可以refactor。毕竟，怎么简单地想问题比怎么分解复杂问题可能还是要容易掌握一点。
不过，co对经验的要求稍微小一点，但是对数学和逻辑的基本功要求则多了一点。有了一些数学和逻辑方面的基本功，那么设计组合子就会轻松的多。
co也要有一点点运气。所以遇到你怎么想也想不明白的情况，就别死抗啦，也许这个问题就抽象不出组合子来，或者以我们普通人的智慧抽象不出来。
co是银弹吗？当然不是，至少以我的功力没有这种自信。 遇到复杂的问题我也是先分解需求，面向接口的。只有问题的规模被控制在了一定的范围，我才会试图用co来解决问题。靠着对co的一些经验和感觉，一旦发现了可以组合子化的概念，成果会非常显著。
而且，co和oo关注的层面也不同。co是针对一个单独的概念（这点倒有点象ao），一点一点演绎，构成一个可以任意复杂的系统，一个好的co也 会大大减少需要引入的概念数。而oo是处理大量互相或者有联系，或者没有联系的概念，研究怎么样把一个看上去复杂的系统的复杂度控制住。所以两者并不是互 相排斥的。自顶向下，自底向上，也许还是两手一起抓更好些。
这段时间应用co做了几个软件后，感觉co最擅长的领域是： 问题域有比较少的概念，概念简明清晰（比如logger, predicate, factory，command），但是对概念的实现要求非常灵活的场合。 这种时候，用oo就有无处下嘴之感。毕竟概念已经分解了，职责也清楚，就是怎么提供一个可以灵活适应变化的体系，而对这个，oo并没有提供一个方法论。基本上就是用po的方法吭哧吭哧硬做。而co此时就可以大展用武之地。弥补这个空隙。
看过圣经的，也许有感觉，旧约里面的上帝严厉，经典，就像是一个纯粹的fp语言，每个程序员都被迫按照函数式，组合子的方式思考问题，你感觉困难？那是你不够虔诚。你们人不合我的心意，我淹死你们！
而新约里面，明显添加了很多人情味儿。上帝通过自己的儿子和人们和解了。既然淹死一波，再来一波还是这样，那么是不是说大家应该各让一步呢？ co和oo，既然各自都不能宣称自己就是银弹，那么为什么不能拉起手来呢？我们不是神，不可能真正按照神的方式用基本粒子组合演化世界，所以就别 象清教徒一样苦苦追求不可能的目标了。但是，上帝的组合之道毕竟相当巧妙，在有些时候荆棘里面出现火焰的时候，我们又何必固执地拒绝造物主的好意呢？礼貌 地说一声：“谢了！老大”。不是皆大欢喜？
这一节我们继续讲解了这个logging的例子。实际上，logging是一个非常简单的组合子，下面如果大家对这个例子有疑问，我会尽力解答。
然后，我们会进军下一个例子。